Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/hacklist/94-04.Z/94-04/[e-mail]_Tue Apr 19 09:50:13 1994.msg

Internet Message Format | 1994-04-30 | 17KB

Received: from mica.inel.gov by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA08525; Tue, 19 Apr 1994 17:49:38 -0400
Received: from dewey.inel.gov (dewey.tis.inel.gov) by mica.inel.gov
    (4.1/INEL-MH-10.0) id AA19799; Tue, 19 Apr 94 15:49:36 MDT
Received: by dewey.inel.gov (5.65/INEL-WKS-2.0)
    id AA18762; Tue, 19 Apr 1994 15:50:13 -0600
Date: Tue, 19 Apr 1994 15:50:13 -0600
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: a redirecting DLL


Hi folks,

How does one go about making a redirecting DLL?  For instance, if one had
the need to intercept all messages going to, say, WINSOCK.DLL, how would
you do this?

A simple example of such a DLL might be something that showed requests and
responses.  This would be a kind of "pass through" DLL, not very involved
at all, and once it worked correctly it could be a great diagnostic tool,
among other things.

A little more involved DLL might be something that implemented one of the
proxy protocols, say SOCKS.  With such a DLL all WinSock clients would
instantly become SOCKSified; well, in my dreams, of course, but it would
probably work well for the majority of clients.

If anyone can point me to some reference materials, or other helpful
information, I would certainly appreciate it.  Also, if I developed it here
at work, I would try to make it freely available, like wslpd and WSGopher
are now.  Chances are good that I'd succeed.

Thanks in advance!

Best regards,
Dave

-------------------------------------------------------
David L. Brooks
Idaho National Engineering Lab.  INTERNET: [e-mail]
POB 1625                         Phone: [phone]
Idaho Falls, Id. 83415-3730     FAX:   [phone]
-------------------------------------------------------
From [e-mail] Wed Apr 20 02:14:13 1994
Received: from jsbus.jsbus.com (jsbus.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA20754; Wed, 20 Apr 1994 12:15:08 -0400
Received: by jsbus.jsbus.com id aa12214; 20 Apr 94 9:15 PDT
From: Martin Hall <[e-mail]>
To: [e-mail], [e-mail]
Subject: *** WinSock 2 Announcement ***
X-Mailer: SCO Portfolio 2.0
Date: Wed, 20 Apr 1994 9:14:13 -0700 (PDT)
Message-Id:  <[e-mail]>

This is a little later than we'd intended because of various things
we've wanted to finalize...

Here's important data for all of you interested in the NEXT
version of Windows Sockets. Please note we've worked hard to
try and incorporate all suggestions and experience into this.
If you have ideas or requests, it doesn't mean you've lost your
chance. On the contrary, your participation is encouraged.

Please note, however, that we don't want to start email
discussion of the following until AFTER the Interop meeting.
Following that meeting we will publish details of
that meeting and any refinements to the following. THEN
we will get into the real technical discussions. So please
hold of with WinSock 2 email until then.

thanks everyone
Martin (on behalf of Martin, Dave & Mark)

---------------------------------------------
Windows Sockets Version 2 - Kick Off Details
---------------------------------------------

Date:    April 18, 1994
Authors: Martin Hall, Dave Treadwell, Mark Towfiq

This document is organized as follows

1. Objectives (Why are we doing this?)
2. Overview  (What's it all about?)
3. Organizational Framework
        3.1 Moderators
        3.2 Review Boards
                3.2.1 Application Review Board
                3.2.2 Transport Review Board
        3.3 Design/Functionality Groups
                3.3.1 Generic API Extensions & Additions
                3.3.2 Specification Clarifications
                3.3.3 Name Resolution
                3.3.4 Operating Framework
                3.3.5 TCP/IP
                3.3.6 IPX/SPX
                3.3.7 Appletalk
                3.3.8 Telephony
                3.3.9 OSI
4. Timeframes
5. Discussion Forums
6. Key Dates
7. Actions Required

--------------------------------------
1. Objectives (Why are we doing this?)
--------------------------------------
Windows Sockets has succeeded to date because
1. It has met the needs of application developers ("I'm tired of all these
different API's!")
2. It has led to easier decisions for end users ("I want a WinSock app, I
want a WinSock compliant stack and I want them now!")
3. It's been fun and pursued in a great spirit of cooperation

The burgeoning implementation of LAN environments, the rise and rise of
TCP/IP, the widespread acceptance of Windows Sockets in the application
developer community and amongst application users have all helped make
Windows Sockets something of a de facto standard in a very short period of
time. It is therefore natural to consider amending and extending Windows
Sockets to make it the de facto transport API for all data communication
irrespective of protocol.

----------------------------------
2. Overview (What's it all about?)
----------------------------------
The Windows Sockets Version 2 specification will extend Windows Sockets
Version 1.1 in 3 key areas

1. API Extensions
Over 2 years experience of Windows Sockets has led to various suggestions
for improvements to the existing specification. There are a number of
proposals for API additions and extensions which make it even easier for
application developers to utilize Windows Sockets implementations.
Some of these extensions are likely to be generically applicable, some will
be transport specific.

2. Multiple Network Transport Capabilities
The success of version 1.1 of Windows Sockets has led to a clamour for
support of network transports other than TCP/IP. Requests have been
made to design support for IPX/SPX and AppleTalk specifically.
In response to demand for a standard data transfer API for emerging
technology such as ATM and telephony-based transports, there will also be
consideration of how best to enable this in a Windows Sockets framework.
The design groups in Windows Sockets 2 will also seek to create a generic
architectural framework that will host any network transport.

3. Operating System Considerations & Architectural Issues
The Microsoft Windows Operating System platforms will soon be extended
beyond Windows 3.1 and Windows NT for which Windows Sockets 1.1 was
designed. Windows Sockets Version 2 will take into account not just
these platforms but forthcoming versions of both Windows NT and
Chicago. An important goal of WinSock 2 is thus ensuring that WinSock
applications can be well-integrated within these operating systems.

---------------------------
3. Organizational Framework
---------------------------
The success of Windows Sockets 1.1, the complexity and breadth of issues
under discussion for Windows Sockets version 2 and the number of people
now involved in the various Windows Sockets forums means we need a little
clearer operational structure for progress this time around.

In order to allow everyone to contribute to areas which they care
about we have designed the following operational structure to
facilitate discussion and to enable maximum progress. The most
important groups are the Review Boards and Functionality/Design Groups.
Together, these groups will be responsible for discussing, designing and
agreeing on the practicality of new functionality.

--------------
3.1 Moderators
--------------
Martin Hall, Dave Treadwell and Mark Towfiq will act largely as
coordinators.

------------------
3.2 Review Boards
------------------
The reason for establishing Review Boards is to enable the ongoing
pragmatic goals of Windows Sockets to be realized. In the world of
Windows Sockets, pragmatism is defined by

1. The applicability of Windows Sockets functionality to application
   developers.
2. The ease with which functionality can be implemented by
   Windows Sockets providers (typically, but not necessarily,
   network transport vendors)

To this end, we would like to set up 2 review boards. Each board will
review submissions from each Functionality Group in the light of the
pragmatic goals of Windows Sockets.

3.2.1 Application Review Board
-------------------------------
Charter: The Application Review Board will review submissions from
         each Functionality Group. It will focus on the submission's
         applicability to and ease of use by application developers as
         well as confirming that functionality required by applications is
         supported.

Membership: A maximum of one representative from each company will
            contribute to this group.

3.2.2 Transport Review Board
-----------------------------
Charter: The Transport Review Board will review submissions from
         each Functionality Group. It will focus on the ease of
         implementation of a piece of functionality.

Membership: A maximum of one representative from each company will
            contribute to this group.

3.3 Design/Functionality Groups
-------------------------------
The reason for establishing Design/Functionality Groups is to break up the
large body of issues that require discussion for WinSock 2 into manageable
chunks. The following groups will also allow people to focus on areas of
particular interest and ignore ones they don't care about.

3.3.1 Generic API Extensions & Additions
-----------------------------------------
Charter: To design and specify general extensions to the Windows Sockets
         API. Features and changes should be applicable to multiple
         transport protocols.

Proposals:
    Improved support for other languages: C++, Basic, Pascal
    True asynchronous send() and recv() mechanisms
    Ability to share sockets between tasks/processes
    "Deferred accept()"--don't establish connection immediately
    SO_SNDTIMEO and SO_RCVTIMEO socket options
    4-byte per-socket context value stored by winsock DLL
    Standard routine to map winsock error codes to strings
    Aplication yielding, blocking hooks
    Socket Groups
    Support for message-oriented (partial) receives
    Per-socket query of max message length
    Support for connect and disconnect data
    Transaction-oriented transport support
    Mechanism for querying optional functionality
    Scatter write, gather read
    sethostname()
    Mechanism to retrieve network statistics

3.3.2 Specification Clarifications
-----------------------------------
Charter: Resolve ambiguities in the Windows Sockets specification to
         ensure that all Windows Sockets implementations have a
         consistent interpretation of the interface.

Proposals:
    WSAAsyncSelect() issues
    Multiple versions supported by a single winsock DLL
    Unconnecting datagram sockets
    FD_CLR performance improvements
    s_port in servent struct is int
    Stack space requirements on winsock DLL
    NULL array pointers in hostent struct
    Structure packing of servent, protoent
    winsock.h: all ports, ip addrs in NETWORK order
    closesocket() on nonblocking sockets
    Samples for every API
    FD_READ contains error--> no need for recv()

3.3.3 Name Resolution
----------------------
Charter: Design and specify a name-service independent interface which
         allows Windows Sockets applicationt to resolve huiman-readable
         host or service names into Windows Sockets transport addresses
         (SOCKADDRs).

Proposals:
    Support for other name service providers
    Host/Service enumeration
    Internationalizable (unicode) name resolution routines
    Dynamic service registration
    Directory Service support
    Define standard location for database files

3.3.4 Operating Framework
--------------------------
Charter: Ensure that Windows Sockets DLLs and transport protocols can
         coexist in the various operating systems which support Windows
         Sockets.

Proposals:
    Operating System versions--Win 3.1, WFW, NT, Chicago
    Configuration
    Architecture
    Multiple Transport Procotol Stacks on a single host
    Multiple Windows Sockets DLLs on a single host
    Clearinghouse for address familys, protoocls, socket types
    Mechanism for determining version of winsock DLL

3.3.5 TCP/IP
-------------
Charter: Provide TCP/IP-specific extensions to the Windows Sockets API.

Proposals:
    ICMP, Raw Sockets, Ping
    RFC 793 & 1122 OOB Data support
    Get/Set/Delete ARP entries
    gethostid()
    SIOCGIFADDR, SIOCGARP, SIOCGHIWAT, SIOCGIFNETMASK, SIOCADDRT, etc.
    Mechanism to set TTL in IP header
    rresvport()
    IP multicast support (IGMP)
    IPng support
    UDP datagram send size != receive size
    Standardize OOB handling
    Option to disable UDP checksum

3.3.6 IPX/SPX
--------------
Charter: Provide IPX/SPX-specific extensions to the Windows Sockets API.

Proposals:
    No specific ones as yet

3.3.7 AppleTalk
----------------
Charter: Provide AppleTalk-specific extensions to the Windows Sockets API.

Proposals:
    No specific ones as yet

3.3.8 Telephony
----------------
Charter: Extend Windows Sockets to handle telephony applications
         including atm, isdn, etc.

Proposals:
    Lots of interest

3.3.9 OSI
----------------
Charter: Provide OSI-specific extensions to the Windows Sockets API.

Proposals:
    No specific ones as yet

--------------
4. Timeframes
--------------
We have identified the following broad and hopefully realistic timeframes
for Windows Sockets Version 2.

May (Interop)     - Windows Sockets 2 Kick Off (See below)
June 30, 1994     - Functionality Groups Functionality Proposals
                    Complete
August 31, 1994   - Functionality Groups First Drafts Complete
November 30, 1994 - Functionality Groups Intermediate Drafts Complete
January 1, 1995   - Functionality Groups Final Drafts Complete
April 30, 1995    - Windows Sockets Version 2 Specification Final

---------------------
5. Discussion Forums
---------------------
Email & Newsgroup details

With the recent reorganization of the Windows newsgroups, we see a need
to:

1. Create a new list for WinSock 2.0
2. Shift the mailing list gated to alt.winsock
3. Re-think winsock-hackers and winsock-users.

Here are the new networking-related newsgroups

comp.os.ms-windows.networking.tcp-ip     Windows and TCP/IP etworking
comp.os.ms-windows.networking.windows    Windows' built-in networking
comp.os.ms-windows.networking.misc       Windows and other networks
comp.os.ms-windows.programmer.networks   Network programming

For the current mailing lists we propose to
1. Gate the present winsock mailing list to
comp.os.ms-windows.networking.tcp-ip
 (since, although winsock is not only for TCP/IP, 95% of the traffic on the
mailing list is about TCP/IP).
2. Gate winsock-hackers to comp.os.ms-windows.programmer.networks.
3. Drop winsock-users because of minimal usage.

For Windows Sockets Version 2 discussion we propose to
1. Create a new mailing list,[e-mail], for
discussion of general issues related to Windows Sockets version 2.0.
2. Create separate mailing lists for individual Review Boards and
Functionality Groups.

None of these will be gated to a newsgroup, to facilitate focussed
discussion.

-------------
6. Key Dates
-------------
April 21, 1994, TCP/IP Bake-Off, hosted by Microsoft, Seattle WA
        Windows Sockets 2 - Informal evening dinner meeting

April 21 - 22, TCP/IP Bake-Off, hosted by Microsoft, Seattle WA
        WinSockathon IV

Tuesday May 3 1994, Interop, Las Vegas NV
        Windows Sockets 2 - Official Kick Off

--------------------
7. Actions Required
--------------------
The official Windows Sockets 2 kick-off will take place at Interop, Las
Vegas. Interop is really the godfather of Windows Sockets so it's a
particularly appropriate venue.

If you wish to attend that event discussion please

1. Email the following details to Marty Bickford ([e-mail])
        Name
        Company
        Address
        Contact Telephone Phone Number
Please note space is limited and preference will be given to the first
person from a particular company who sends such an email.

2. Consider this document the informal working agenda for now,
   (a formal agenda will be published).



-------------------------------------------------------------------------
Martin Hall                         108 Whispering Pines Drive, Suite 115
JSB Corporation                     Scotts Valley, California 95066
[e-mail]                   Tel: [phone]   Fax: [phone]